Motivation:

Our implementation has maintained a VertxSslContext wrapping an SslContext to configure a few aspects of the SSL engine. This does not seem necessary anymore since SslContext has all the necessary configuration options on the SslContextBuilder.

Changes:

Update the SslContextFactory to handle the configuration aspects VertxSslContext was implementing.

Remove VertxSslContext wrapper and configure the options instead on the SslContextFactory.

…nection

Motivation:

ConnectionBase carries a reason/timeout set of interactions for closing a connection that is superfluous for ConnectionBase since users of it are subclasseing VertxConnection.

We aim to have ConnectionBase more reusable and universal for non vertx based connections (such as HTTP/2) yet retain this for vertx based connections (HTTP/1.1, WebSocket).

…t part of NetSocket which is a TCP socket

Motivation:

Letting VertxConnection subclasses manage the shutdown handler gives more flexibility and is a concerned removed from the VertxConnection that focuses on its state management and control flow without caring about interactions.

…lass.

…class.

Motivation:

Since only WebSocket use an effective close reason, we should move this generic part of the VertxConnection to WebSocketConnection implementation to simplify unclutter VertxConnection and keep it focus on its responsibitlies.

Motivation:

The VertxConnection relies on Netty channel close, instead it should be separate and keep channel close as short as possible.

…ionGroup class

Motivation:

NetServer and NetClient both combine a close sequence with a channel group to implement graceful shutdown of an endpoint.

We should encapsulate it to share the code between NetServer and NetClient and reuse it in Quic.

…ed by GC

Motivation:

Quic can be properly supported since it is out of incubation from Netty, it provides a new transport for building middlewares on top of it. Although HTTP/3 is currently the only protocol specified on top of Quic, there are discussions and will to port other protocols on top of Quic.

While the purpose is similar to NetClient/NetServer there are a few significant differences that would make the `io.vertx.core.net` API reuse.

- QUIC mandates TLS and does not support TLS upgrade
- QUIC requires to bind a _physical_ UDP socket on client and server prior other interactions
- QUIC provides connections multiplexing streams
- A connection can be closed with a reason
- Streams can be single duplex or full duplex
- Server load balancing operates in a different fashion

Vert.x can facilitate the usage of Quic in the Java ecosystem by providing a comprehensive solution and explore ways of using Netty codecs on top of Quic.

This feature provides an API to interact with Quic transport as a server or a client, very much like the existing TCP socket API. It also provides an internal API to interact with the underlying Netty configuration to plugin codecs and use messages instead of buffers.

Changes:

Quic API and implementation.